Hi all, |
Re: deleted objects not there? |
Re: deleted objects not there? what happened in the meantime: wrote a script to print the absolute numbers of deleted objects: they are all in a row and preceding and following numbers are from table objects (go tell users not to use DOORS tables ...) then told the script to undelete the objects. next 'Purge all' tells me there are no objects to delete. try to navigate to one of the undeleted objects: object cannot be found. ?? |
Re: deleted objects not there? kabr - Thu Jul 28 11:43:47 EDT 2011 It sounds like someone has deleted a table and then purged only the visible table cell objects - the Table menu lets you do this (purge by cell or by row). If you purge all visible table cells one by one, DOORS doesn't have the intelligence to do the housekeeping and clean out the hidden table and row marker objects, they just stay there hidden away. Given that you also indicated that you cannot navigate to the objects that your script found then I'm pretty sure that confirms my hunch that these are hidden table & row marker objects - should be safe to purge them. And you're right in your statement "go tell users not to use DOORS tables .." - the general convention with DOORS is to create tables in MS Word or MS Excel and then insert these as an embedded OLE into a DOORS object. Only use DOORS tables if they will be small and simple and you place a high value on being able to link to individual cells and have full change tracking etc. Regardless of the limitations of tools like DOORS - it just good Requirements Engineering practice that where ever possible, keep tables small as large complex tables are prone to errors in interpretation and are a pain to manage in general. Paul Miller Melbourne, Australia |
Re: deleted objects not there? SystemAdmin - Thu Jul 28 21:58:26 EDT 2011 Paul Miller Melbourne, Australia Yes, I am quite sure that the objects are from a DOORS table, but with their absolute numbers all in one row (11329 - 11341) I find it rather unlikely that they are all table header and row objects. And yes, I even had the idea which you described, that a user purged the cells one by one, and I tested this. But in that case you will still be able to see the table marker in the module explorer or as deleted in the main column when table cells are hidden. I agree with you that it will be safe to purge the objects, but still an uneasy feeling remains ... Karl |
Re: deleted objects not there? Yes table/row header objects, which can be identified with "if (table(o) or row(o))". Seems to me you can SEE them if you don't view Tables at all; you end up seeing just the table header object where the table is supposed to be. Perhaps this is useful:
bool IsEmptyRow(Object oRow)
{ // Is the object a Row Header with no subordinate cell objects?
Object oCell
if (null oRow) return(false)
for oCell in oRow do
{ return(false) // found one cell
}
return(true) // Get this far?
} // end IsEmptyRow()
bool IsEmptyTable(Object oTable)
{ // Is the object a Table Header that may have rows but has no cells?
Object oRow
if (null oTable) return(false)
for oRow in oTable do
{ if (!IsEmptyRow(oRow)) return(false) // found row that has a cell
}
return(true) // Get this far?
} // end IsEmptyTable()
for obj in entire mod do
{ if (isDeleted(obj) and IsEmptyTable(obj)) print identifier(obj) "\t" number(obj) "\tIs deleted empty table\n"
}
|